(1) Field of the Invention
The present invention relates to a program development system which is made up of a debugging apparatus which, during software development, can check that execution code generated by a program conversion apparatus operates as intended and which can quickly discover any errors present in such code, and a debugging information generation apparatus for generating debugging information for the debugging apparatus.
(2) Description of the Related Art
In recent years, model changes for information processing equipment, such as word processors, home computers, and electronic notebooks, and for domestic electrical appliances, such as videos, televisions, and refrigerators, have become remarkably frequent. Consequently, the development period of such information processing equipment and domestic electric appliances has also become extremely short to allow such rapid model changes. As a result, manufacturers are constantly under intense pressure to complete the development of new products in such a short time. On the other handy the installation of microcomputers into such information processing equipment and domestic appliances is now taken for granted, so that the rapid development of a control program for such embedded microcomputers has become a vital task for the technicians of each manufacturer.
In this present situation, an increasing amount of attention is being given to the provision of a "high-level language-oriented development environment" for producing control software. This refers to a development environment wherein all processes from the coding of the program to the testing on the actual appliance can be performed using a high-level language. Here, the key to the provision of such a development environment is the generation of debugging information to enable operation verification to be performed by a debugging apparatus using the high-level language.
Debugging information is a general name given to all information which expresses the correspondence between a program written as the original source code statements and the program in its execution code state. Representative examples of debugging information are line-address information that shows the correspondence between each line in the source code statements and the addresses in the execution code, and allocation information that shows the correspondence between the variables in the source code and the registers and memory addresses used by the execution code. With such allocation information, if correspondence is clearly established between each of the variables, which are freely defined by the programmer and used according to necessity, and each hardware resource, such as a register or memory address, the programmer will be able to control the correspondence between the program written by him/herself and the execution code.
The following is an explanation, with reference to FIG. 1, of the construction of a conventional debugging apparatus which uses the kind of debugging information described above.
The debugging apparatus shown in FIG. 1 is made up of a program storage unit 301, a generated code storage unit 302, an optimization information storage unit 303, a debugging information storage unit 304, an input unit 401, a code execution unit 402, a variable operation unit 403, an output unit 404, and a line display unit 405.
The program storage unit 301 stores a program which is written by technicians using a high-level language.
The generated code storage unit 302 stores the generated execution code.
The optimization information storage unit 303 stores the allocation information for the program stored in the program storage unit 301.
The debugging information storage unit 304 is made up of a line-address storage unit 3041, which shows the correspondence between the lines in the program and the addresses of the execution code, and a function information storage unit 3042, which expresses function information. This function information in the function information storage unit 3042 includes a starting address for a function, the names and forms of the arguments and variables of the function, and, when a variable is held in the stack, an offset value for the stack.
The input unit 401 receives indications of variables whose values are to be set by a user and variables whose stored values are to be referred to.
The code execution unit 402 executes the execution code which it receives from the generated code storage unit 302.
The variable operation unit 403 receives the allocation information for a variable indicated by the input unit 401 from the optimization information storage unit 303 and the debugging information storage unit and determines which resource has been allocated the indicated variable. Here, "resources" refers to the registers or stack addresses in the execution code which have been allocated to express the variables. Having determined the resource as described above, the variable operation unit 403 asks the code execution unit 402 the value of the resource. After receiving the value of the resource, the variable operation unit 403 has the variable and its value displayed by the output unit 404.
The line display unit 405 receives the program from the program storage unit 301 and displays the function which includes the halt line.
The following is an explanation of the operation of the debugging apparatus of the construction described above. The content of the program storage unit 301 is shown in FIG. 2A. The content of the generated code storage unit 302 is shown in FIG. 2B. The content of the debugging information storage unit 304 is shown in FIG. 2C. The content of the optimization information storage unit 303 is shown in FIG. 2D.
When the debugging apparatus is activated, the line display unit 405 displays the program in function units, and the input unit 401 displays the command line and waits for a user input. If in this wait state, the user inputs a command which signifies a reference of the value of variable z on the tenth line (see FIG. 3A), the variable operation unit 403 searches the line-address storage unit 3041 and finds the address which corresponds to Line 10. For the example content of the line-address storage unit 3041 shown in FIG. 2C, Line 10 corresponds to the address "0.times.128". Once it is established that Line 10 corresponds to address "0.times.128", the code execution unit 402 is ordered to set a breakpoint at address "0.times.128" and the line display unit 405 is ordered to display Line 10 with an arrow. By displaying such an arrow, the user is informed of an execution of the program as far as line 10 (see FIG. 3B). The code execution unit 402 then executes the execution code stored in the generated code storage unit 302 as far as the address "0.times.128" which is set as the break point. Once the execution code has been executed as far as address "0.times.128", the variable operation unit 403 searches the optimization information storage unit 303 and determines which resource has been allocated to the indicated variable z. For the example content of the optimization information storage unit 303 shown in FIG. 2D, the resource allocated to indicated variable z is the register D3. Accordingly, the variable operation unit 403 obtains this register D3 from the optimization information storage unit 303 and instructs the code execution unit 402 to read the value of register D3. On being thus instructed the code execution unit 402 reads the stored value "10" of the data register D3, and the variable operation unit 403 instructs the output unit 404 to output the read value "10" as the stored value of the variable z. On being thus instructed, the output unit 404 displays the variable name of variable z together with the stored value "10" (see FIG. 3C).
As described above, the user inputs a variable name, and the resource to which the inputted variable is allocated is determined using the variable-resource correspondence information. Following this, the code execution unit outputs the value or the resource so that the user can know the value of each variable when the program is executed in its execution code state on the intended machine.
The disadvantage of such debugging apparatuses which improve the efficiency of program development using correspondence between variables and resources lies in their inability to show the user the content of the optimization executed inside the program conversion unit, so that when the program is greatly rewritten by the internal processing of the program conversion unit, it will take the user a great deal of time to comprehend how his/her program has been rewritten.
For example, when a user wishes to change the value of a variable, if a subexpression containing the variable in question is rewritten into a temporary variable, such a change in value will not be possible unless the user can grasp the correspondence between the temporary variable and the original subexpression. Here, if the user attempts to change the value of a variable without properly understanding the correspondence between the temporary variable and the subexpression, there is the danger that the changing of the variable can lead to erroneous operation by the program.
A new debugging method has disclosed by Japanese Laid-Open Patent Application 6-274369. In this method, the program conversion apparatus is made to analyze the changes in source code statements before and after optimization, and to generate information which shows the progression of these changes. More specifically, when there is a variable in the source code statements which is rewritten into a different variable, the program conversion apparatus analyzes which resource has been allocated to the rewritten variable and generates information which shows "pre-replacement variable-resource" pairings.
As an example, when the subexpression "2+*n" in the source code statement "s=s+2*n" is replaced with the variable "n1" during optimization, analysis is performed to find the resource which has been allocated to the substituted variable n1. If the result is resource R6, information is generated which shows that the variable "n" in the present operation expression is expressed as "R6/2".
Problem which the Present Invention is Attempting to Solve
However, the "pre-replacement variable-resource" or "format of expression including the variable and resource" information of the method disclosed by Japanese Laid-open Patent Application 6-274369 have still not been able to fully express the details of the complex optimization processes which rewrite the source program, such as "replacement of variables", "deletion of lines", and "movement of lines".
The internal processing of the optimization is made up of combinations of fundamental algorithms, such as the deletion of source code statements, the movement of source code statements, and the substitution, movement, or deletion of variables. Here, the program conversion apparatus generates temporary variables according to its needs which it then uses to perform optimization. For conventional debugging methods, on the other hand, when the variables in source code statements are replaced with other variables during optimization, and other source code statements are deleted or moved after such replacement, the "pre-replacement variable-resource" information and "format of expression including the variable and resource" information are generated based on the program in its final state after all these optimization operations have been performed.
When the replacement of variables and the combining of lines are relatively simple, it is probably worth the technician's while to view the generated information, but when the replacement and combining of lines are more complex, it becomes difficult to grasp the details of the generated information, which increases the workload for technicians.
Here, it is possible to conceive of a standardization of the method for expressing debugging information to express the details of the processes performed by established well-known optimization methods, such as "copy propagation", "constant propagation", or by any other new optimization method. However, such new optimization methods are being constantly developed and introduced, so that even if a method for expressing debugging information is standardized for established optimization methods or optimization methods which are currently subject to a lot of attention, there is the danger that such a standard would be out-of-date with respect to any new methods being developed.